Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/terms/kermit/a/msvv90.bwr

Text File | 1991-03-17 | 13.4 KB | 281 lines

Problems with MS-DOS Kermit 2.29 on the Victor/Sirius:

When you SEND from the host, escape back, and RECEIVE on the Victor, the host
Kermit never receives the Victor's final ACK to the host's B packet.  So the
Victor needs a slight pause after sending the ACK to the B packet before
returning to wherever it's going, to give the ACK time to escape from the port
before the door slams shut on it.

There's no way to type ^] on the Victor keyboard, so Victor Kermit should
have a SET ESCAPE command in its MSKERMIT.INI file for some other character
that can be typed on it, like Alt-tilde.

------------------------------

Date: Tue 17 Jun 86 09:22:53-EDT
From: Frank da Cruz <[e-mail]>
Subject: Victor/Sirius Kermit
To: cuddy@UMKCVAX1, PETERSON@BYUVAX

Here's a complaint from a Victor 9000 (Sirius 1) user in Israel, about version
2.29 of Kermit.  I have checked his complaints on some Victors we have here at
Columbia and have found that none of the symptoms he reports occur here.  Can
any of you reproduce these symptoms on your Victors or Sirius's, or suggest any
reason why they would occur on his?  I've heard that there's considerable
variation among Victor machines, depending on exactly where and when they were
manufactured.  I also don't quite know what he means by "not using standard
DOS initialization for the communication port"...  Also, I suspect the last
point has something to do with switch settings on his modem...  Thanks for any
tips you can give.  - Frank

                ---------------

Date: Mon,  16 Jun 86 16:08:05 +0300
From: Meyer Wolf  <[e-mail]>
Subject: Victor/Sirius KERMIT

Dear Mr da Cruz:

Greg Scott of the Linguistics Dept. told me I might write directly to you
concerning the problems I'm having with Victor/Sirius KERMIT V2.29 6 May 86.

1. When KERMIT comes up, it issues the following warning:

        ?Warning Cannot open com port

        Enter a file handle...

followed by a request

        Handle:

After replaying this three times, KERMIT issues the message

        ?Not confirmed

and continues as if nothing is wrong. The three numbers I reply with are
4, 3 and 2 in that order. Other numbers either crash KERMIT or disable its
ability to execute DOS commands such as DIR & TYPE.

The request for a file handle is probably a result of my not using standard DOS
initialization programs for the communication ports; presumably KERMIT looks
for some trace in the operating system and fails to find it. Can you tell me
what it is?

2. The MSKERMIT.INI initialization file is recognized and executed by KERMIT
   when it comes up. However macro definitions included in MSKERMIT.INI are
ignored. Consequently "set esc ~" does just that but "define foo set prompt
Foo>" does not make the macro foo available (as executing the SHOW MACROS
command confirms).

Incidentally, I did not get an initialization file with the executable KERMIT
file MSKV90.EXE; the IBM macro that you may have noticed is built in.

3. Unlike earlier versions of Victor/Sirius KERMIT, V2.29 insists on half-
   duplex when addressing a MODEM in CONNECT mode. Setting LOCAL-ECHO ON
sets full-duplex, but not only locally: display from the remote machine also
appears with full-duplex, i.e. doubled. Can the former defaults be restored?

Thank you for your trouble.

Yours,

Meyer Wolf

------------------------------

Date:     Mon, 30-JUN-1986 22:21 MDT
From:     Bryan Peterson <PETERSON@BYUVAX>
Subject:  Response to comments of Meyer Wolf, 16 June 1986
To:       fdccu@cuvma

Responding to each question in turn:

1.  The warning about not being able to open the COM port.

This is caused by some (supposedly) smart things we did to keep from smashing
the COM ports too bad when we initialized them and/or changed parameters.  This
is done by opening the device SERIALA or SERIALB (depending on which port is
currently active) with a handle and using the device control function provided
by DOS to set up the parameters.  The actual transfer of data to and from the
port is done directly at the hardware level to insure that no characters will
be lost at the higher speeds.  If the appropriate device name can't be found,
such as if the serial port drivers have been replaced, than a handle can be
provided which is opened for the desired device already.  If the device you
wish to access is also the standard auxilliary device (set with the CAUX
command) then handle number 3 is already open on that device and if it is the
printer device (set with the CLST command) then handle number 4 is already
open.  But be warned, that KERMIT is expecting the device driver to handle the
device control i/o in exactly the same way that the Victor-supplied drivers
handle it.

2.  DEFINE commands in the file MSKERMIT.INI

I am not sure about this one.  I tried a few simple cases and it seemed to pick
up the macro definition just fine from the file.  The only thing I can suggest
is that maybe there is some subtle interaction during the handling of the INI
file which would cause KERMIT to ignore the macro definitions under certain
circumstances.  That part of the code is shared with that of all other MSDOS
implementations of KERMIT - I will plead ignorance at this point (in the
terminology I heard once regarding the VAX VMS operating system, that's not a
bug, it's an undocumented feature!)

3.  LOCAL ECHO behavior.

The way the local echo is handled is to put every character on the screen which
is typed at the keyboard and every character that comes down the serial line.
It is assumed that the remote system will not be echoing keyboard input
(half-duplex operation) so they must be locally echoed.  If you find that
everything is being doubled, the remote system is actually operating in full
duplex and you should turn local echo off - there is no need for the local
system to immediately put keyboard input on the screen since the remote system
will take care of that for you.


I hope these items may help to answer the questions.  The only one I can really
speak with authority on is the first one, since I wrote the section that does
the port handling along with Andreas Stumpf in Germany.  If you want to change
that behavior to match the device drivers you have, it will be necessary to go
through the file MSXV90.ASM and modify all the port initialization and access
routines.  There are bits and pieces of the device control access to the device
driver throughout the routines because we (I) were trying to maintain the
device driver in a state that would allow it to be used by other packages
without requiring a full initialization and so that the portset utility would
return the true port settings after KERMIT was run.  If you have any questions
about the necessary changes, drop me a line and I will be glad to give any
hints on where to look for the places to change.

                                        Bryan Peterson
                                        Bitnet Peterson@Byuvax

------------------------------

Date: Fri 16 Jan 87 13:07:37-EST
From: Charles Lasner <[e-mail]>
Subject: Victor Kermits

I am connected with various and sundry Victor 9000 (AKA Sirius 1 in Europe)
users and vars. We had hoped that a viable KERMIT was available for this
MS-DOS-based machine which is incompatible with (and I daresay better than) the
IBM PC. We eventually contacted someone within Columbia for the Sirius KERMIT
and we had the ancient KERMIT for the Sirius one and MS-DOS version 1.25 with
Victor I/O subsystem 2.5.

A note on this version:

While it is true that this version is ancient and (somewhat) obsolete since it
only handles ascii files properly and can't GET anything, it turns out that it
can be patched to run on a slightly newer version of MS-DOS known as version
1.25 with Victor I/O subsystem 2.61. The source file reveals this and should be
updated to run 2.61 I/O as virtually no-one does anything earlier anywhere in
the world. As to reasons for running 1.25/2.61: many Victor users only have
128k (original system memory without expansion boards (which go up to 898k) had
128k, newer production motherboards now have 256k in different chips
(incompatible) and there is no incentive to upgrade the motherboard though it
*can* be done). A perhaps worse problem: Early Victor 9000 motherboards use a
bootstrap rom set now obsolete which cannot bootstrap anything past MS-DOS
v1.xx systems due to Victor-enspired changes. Many (European) users have old
boot chips and can't run MS-DOS 2.x even if they have the memory! It is
probably true that these users will not upgrade, as they have little incentive
to do so, and I presume that Columbia wants to stay neutral on this problem.

My Victor 9000 had recently been bootstrap rom-wise upgraded, so I could run
small MS-DOS 2.11 programs, but only had 128k. Since I only had MS-DOS
v1.25/2.61, I had to spend major amounts of time convassing local users until
we found someone with an old disk with 2.5 on it. (I didn't know about the
patch mentioned in the source, but it was strange to be defaulting to an
obsolete version) I eventually put up SIRIUS.EXE as supplied and it did work
with the known restrictions, etc. I later obtained via CCnet the MS-KERMIT.BOO
file for Victor 9000 and MSBPCT.BAS de-booing program. Moving the two files
to MS-DOS v2.11 (and obtaining more memory to 256k) I then ran MSBASIC on the
file renamed to MSKERMIT.BOO and had no problems other than waiting for MSBPCT
to convert it. This successfully produced MS-KERMIT for Victor 9000 v2.28 which
was a quantum leap forward. (A minor glitch, the file produced was msv90.exe,
not msvv90.exe as advertised.) This version worked quite well, but had problems
with wildcard GET commands which always mangled the first (even if only) file
matching the filespec. The contents where fine.

More recently I have obtained the latest version (A/O NOV 1986) via the same
path, only using MS-DOS 2.11 for all generations.

Some comments on the current version:

a) when connecting, a message flashs on the screen too fast to read, presumably
advising the escape character usage, etc.

b) when push-ing to MS-DOS to run chkdsk or space or directory, etc., I created
a strange (hard to recreate) effect whereby the receive screen was not present,
even though all other functions worked. The problem is apparently, when you
return from directory listings, etc., you may overlook the need to paint the
screen before initiating the first transfer.

c) apparently all versions can't change CWD to a: or b: (floppies), which I
find a little annoying, as the unit containing MSKERMIT.INI is virtually never
the unit for files. Also other commands take unit constructions: dir b:, take
a:mskermit.ini, etc.

------------------------------

Date: Mon, 12 Dec 88 11:53 MDT
From: Joe Doupnik <[e-mail]>
Subject: Note on Victor 9000 MS Kermit
Keywords: MS-DOS Kermit, Victor 9000

A historical note on Victor 9000 MS Kermit.

Since about version 2.29C of MS Kermit the Victor 9000 copy failed to support
Tektronix graphics. A colleague loaned me his Victor and some Tech Refs. The
reason for the failure became clear: the Victor insists upon locating 40KB of
graphics screen memory in main system memory below the 128KB boundary.
Unfortunately, DOS also loads programs in the same memory without regard for
the graphics region! As the size of MS Kermit has grown over time it finally
squeezed out the last free 40KB in this region and automatically stopped the
graphics support. What an unusual memory map the Victor 9000 has.

I took steps in the 11 Dec version of MS Kermit 2.32/Victor to retain the
graphics memory area.  A consequence is the file MSYV90.OBJ must be Linked
first in the list of object modules; this occurs in the now current MSVV90.LNK
file. If it does not occur first then there will be no Tek graphics.  Also, of
course the 11 Dec or later file MSYV90.ASM is needed to make this effective.

    Regards,
    Joe D.

------------------------------

Date: Tue, 10 Jan 1989 17:44:24 EST
From: Charles Lasner <[e-mail]>
Subject: Victor 9000/Sirius issues.

    A few Victor quirks to add to the .BWR file:

    Apparently the person in Israel is using the GENERIC MS-KERMIT
not the Victor-specific one.  I have never gotten any GENERIC version
to work, and get all of the results he reports regarding the file
handle problem.  THis exists through 2.31 (haven't tried 2.32 yet on
Victor 9000).  What is so non-generic abot Victor?

    The Victor 9000 CAN do control-], but not as supplied.  There
is a standard utility for the 9000 called MODCON which modifies your
keyboard layout, and there are several "semi-standard" variations
around.  I use a file supplied with a VT-100 emulator (EM100) called
V100.KBD which is supplied by the terminal emulator vendor for use
outside of the emulator environment, so that other programs will match
the modified layout (they provide the plastic "colorforms" to stick
over the keycaps that conform to the emulator layout).  The key
combination in question can be stuck anywhere.
    BTW: in Victor parlance, <alt> is really control; there is no
<alt> as in IBM-style keyboards.  The Victor layout resorts to the
unusual notion of "doubling-up" the keys by applying an additional case
to the top row of keys with the <alt> key pressed, for the creation of
ordinary printable characters (like "<" and ">", etc.) besides the
normal shifted and unshifted cases.
Charles Lasner (cjl) (lasner@cunixc)
ps:     the Victor also has trouble with LOG SESSIONS above 1200 baud
presumably because it fails to use DC1/DC3 flow control "in time" to
avoid buffer overflow! (EM100 captures files successfully at 9600
baud.)

------------------------------